故事是這樣的

上一篇的組織內策略討論，讓筆者聯想到一個較小、較短，但也與浪費有關的故事。這是一個開發團隊內部的 Code Review 現場…

「…這個 Repository 用的設定，值是記在設定檔中。我們就用另一個 Repository 來取，在開機時取出後，放在一個系統通用的類別中，用靜態變數存起來…」Jason 剛完成他的大作，興高采烈地向大家解釋這個設計的神妙之處。
「設定檔大家都讀得到，為什麼不讓要用的 Repository 自己讀就好？」團隊較資深的 Andy 問。
「因為這樣，未來有別人要用時，就不用從設定檔再拿一次，比較省效能…」Jason 答道。
「省多少？誰要用？」Andy 繼續問。
「…呃，反正從 memory 一定比從檔案快嘛…而且現在沒人用，不代表我們不能預先用比較 clean 的設計來做呀！」Jason 回答。

我必須讓故事就先到這邊打住，螢幕前寫 code 多年的敏捷信徒們快砸電腦了。

工程師為什麼總是過度設計

Andy Hunt 在 The The Pragmatic Programmer 一書中曾問讀者：「你上次因為一件未來可能會發生的事情做了一個神妙設計，而後來預想中的事真的發生，而這使你為你自己的神機妙算暗中竊喜是什麼時候？」

我大膽猜測，有 87% 以上的讀者根本想不起來這件事上次是何時發生的。也很有可能職業生涯從未發生過。

然而事出必有因，既然過度設計很少派上用場，那麼，為什麼工程師還是這麼常做這件事呢？對此，部落格「搞笑談軟工」作者Teddy Chen 在他的 Youtube 頻道中有一篇影片，分析幾種常見的原因，分別是：

1. 需求不清：需求來時範圍很大，很多地方不確定要做成什麼樣子，也不確定要解決什麼問題，又不敢（或不被允許）發問，只好一律先把所有未來可能的改動全都考慮進去。
2. 超前佈署：需求被改多了，久而久之染上被害忘想症，不管做什麼工作，都一律先把所有未來可能的改動全都考慮進去。
3. 改動架構成本很高：因為核心邏輯與框架（或架構）緊密結合，所以一但需要改設計，會「傷筋錯骨」，非常麻煩，只好一律先把所有未來可能的改動全都考慮進去。
4. 展現技術能力：去上了很厲害的課，學了很先進的科技，回來看自己的專案就看什麼都不順眼，為了展現我很優秀，一律先把所有未來可能的改動全都考慮進去。
5. 演化的結果：一個專案架構變了很多次，維護人員來來換了很多批，連營運方向都改了不少次，自然而然就把所有過去做過的改動全都考慮進去了。

上面五種原因都很常見，但都有一個共通點，就是：「改動成本太高，不想太常改動」。在筆者過去的觀察中，很多技術團隊在轉型敏捷開發時，遇到的眾多阻礙中，追溯其源，大部份也都不出「改動成本」這件事。

改動的確惱人，但需求改變（或修正）好像又是避不了的事情。然而，過去的經驗也不斷重複地告訴我們，即使提前為未來做足了準備，由於需求方更多元豐富的創意，讓這些看似預先做好的神妙設計，大部份也都派不上用場，甚至因為原先的設計太過複雜，反而造成後來修改時更大的阻力，從而付出更大的成本。

成品也是有浪費的

不只程式的過度設計是一種浪費，成品也是會有浪費的。以軟體開發來說，已釋出（Release）但沒人用的功能，就是一種浪費。

RD 也不是吃飽太閒，功能會被做出來，肯定是需求方提了需求。需求方也不是笨蛋，肯定也是做足了功課，認定用戶一定會需要這個功能才會提出需求。那麼，又是為了什麼，會有功能沒人用呢？

很簡單，因為「沒有人真正知道用戶需要（或喜歡）什麼，就連用戶自己也不一定知道」。在統計結果出爐前，我們只能推測，而我們做的這些準備，都只是在提高推測的命中率。不是說準備不重要，只是沒有人有辦法 100% 保證我們現在手上的工作一定會「中」。

你就是沒辦法。

雖然可惜，但很遺憾的，所有花時間研究的功課，開發者的工時，測試的精力，以及維運的成本，一旦功能不被用戶喜愛，都成為一種浪費。

或者，你可以抖個書袋，稱之為：『沉沒成本』。

不做就不用改

這正是敏捷開發想解決的問題。

敏捷開發強調的是『延遲決策』，意思是有任何事情現在還不確定，那就不要決定。不要在情況還混沌不明的情況下一口氣做太多決定。

市場還不明確，那就不要對策略的細節做太多決定；需求還不明確，那就不要對 Solution 的細節做太多決定；未來改動的方向還不明確，那就不要對程式的細節做太多決定。

拿程式細節為例，有實際套用過設計模式的朋友就能體會，要從一個設計模式重構成另一個設計模式是多不容易的一件事情。基本上你就是要花時間回頭拆解成當初還沒套舊模式的樣子，然後再從頭套新模式。可想而知，多數人想到頭就痛，自然就降低了重構的意願，但這是很可惜的事情，因為我們現在才發現新模式比舊模式更適合這個系統，如果無法現在改善設計，那架構就會處在一個『不太舒服』的狀態，非常可惜。

時光倒流，如果你在一開始改變還不明確時，先不急著加上過多對未來的假設而套某個特定設計模式，而只是嚴守紀律，把一些該注意的耦合與內聚問題處理好，等到現在我們對場景有更多了解，發現新模式更適合的時候再來套用，這是成本應該是很低的。

成品的減少浪費：小步快跑

同理，成品的功能設計也是一樣。應該有不少讀者聽過產品功能的 80/20 法則：『80% 的使用者只會用到一個軟體產品的 20% 功能。』當然，如果我一開始就能做完 100% 再釋出產品，當然就可能滿足更多用戶，但是，如果這些功能不是全部都被喜愛，那在這些功能上付出的成本不就浪費掉了嗎？

這時候產品經理（有些團隊是 PO 在做這些事），就非常重要了。事前做足功課後踏入市場，在剛踏進市場時抓準方向，決定先期產品的樣貌，而不陷入過多細節。釋出後持續追蹤表現，持續分析，決定下一步的策略，再走一小步，... 以此類推。

如此一來，萬一決策錯誤，市場反應不佳，想要調整策略，那麼會被浪費掉的成本也是相對較小的。如果各位讀者有聽過『小步快跑』，就是在講這件事情。

謎之聲：「我們都不是神。」

Reference

1. 約耳談軟體
2. The Pragmatic Programmer: Your Journey To Mastery, 20th Anniversary Edition (2nd Edition), David Thomas and Andrew Hunt, Addison-Wesley Professional, 2019
3. 搞笑談軟工 - 為什麼會產生過度設計？https://www.youtube.com/watch?v=Bh8G_fZFgpI&t=9s